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Abstract 


Xnusim  is  an  Xll  Window  Interface  for  the  Multi- Processor  simulator  Nusim.  It  is  a  display 
oriented  interface  between  the  simulator  and  the  user  via  UNIX'sockets  with  graphical 
objects  such  as  menus,  buttons  etc.  It  is  designed  in  such  a  way  that  would  allow  it  to  be 
used  with  other  simulators  of  the  same  class.  This  paper  intends  to  describe  the  functionality 


of  the  objects,  structures  and  program  modules  of  XNUSIM  in  detail . 
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Section  1 

Introduction 


Xnufim  was  built  with  the  intention  of  giving  Nusim  a  more  visual  interface. 
Nusim[NC89]  is  a  simulator  for  the  PPP  ^Parallel  Prolog  Processor)  [Fag87]  which  is  part 
of  the  Aquarius  Project,  at  the  University  of  California  at  Berkeley[DS88],  However,  aside 
from  knowing  the  input-output  semantics  and  the  kinds  of  commands  nusim  accepts  (refer 
Section  5),  Xnusim  does  not  require  knowledge  of  what  level  simulation  is  performed  and 
what  kinds  of  details  are  involved  in  the  simulator,  so  long  as  it  adhere  to  some  fixed  set  of 
criteria  which  will  be  presented  at  the  concluding  section  (Section  6). 

Due  to  this  method  of  interface,  xnusim  should  not  be  difficult  to  be  converted 
to  interface  with  other  simulators,  especially  if  care  is  taken  in  writng  a  simulator  with 
similar  debugging  capabilities.  Section  5  will  describe  methods  of  interfacing  with  xnusim, 
changes  that  can  be  easily  made,  and  will  also  outline  the  criteria  for  writing  a  compatible 
simulator. 

Xnusim  is  an  interface  built  on  top  of  the  X  Toolkit  Library  [MAS89]  under  X 
Protocol  Version  11  Revision  3  1[GSN89,  SG86],  A  brief  introduction  into  the  X11R3  Win¬ 
dowing  system  and  the  XTooikit  along  with  some  of  the  other  software  used  will  be  presented 
in  Section  2.  In  this  same  section,  the  4.3BSD  Communication  Protocol  [LMKQ89]  will  also 
be  discussed;  to  be  specific,  the  use  of  sockets  which  is  what  xnusim  uses  to  communicate 
with  nusim. 

‘The  X  Window  System  is  a  trademark  of  MIT.  Copyright  ©1985,  1986,  1987,  1988  Massachusetts 
Institute  of  Technology,  Cambridge,  Massachusetts,  and  Digital  Equipment  Corporation,  Maynard, 
Massachusetts. 
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Section  3  will  present  an  overview  of  xnusim,  while  Section  4  will  explain  the 
technical  details  that  makes  up  the  complete  xnusim  program  set.  The  concluding  section 
will  discuss  improvements  possible  or  desirable.  Attached  as  appendixes  axe  the  man  page, 
a  list  of  xnusim’s  procedures  and  files  where  they  may  be  found  and  after  that,  a  list  of  the 
entire  xnusim  program  in  C. 


Section  2 

General  System  Requirements 
and  Overview 


2.1  X  Window  System 

The  X  Window  System[SG86]  was  designed  by  MIT  as  a  windowing  system  which 
runs  under  4.3BSD  UNIX  and  several  other  variants  and  has  since  become  available  for 
the  VAX/VMS,  MS-DOS  and  other  operating  systems  as  well.  The  display  server  is  a 
network-transparent  interface  that  accepts  output  requests  from  various  client  programs 
and  handles  user  input  which  could  be  of  the  form  of  keyboard  or  mouse  events.  The  client 
programs  need  not  necessarily  be  located  on  the  same  machine.  The  version  of  X  used  is 
the  X  Protocol  Version  11  Revision  3  System  (X11R3)  [GSN89].  Xnusim  cannot  be  used 
with  X  of  a  lower  protocol  system  since  it  makes  use  of  certain  features  which  had  become 
available  only  in  the  X11R3  system.  It  is  conceivable  that  it  will  run  on  later  releases  with 
minor  or  no  changes  at  all. 

In  order  to  more  easily  implement  the  system,  the  X  Toolkit[MAS89]  was  used. 
It  is  also  believed  that  although  much  of  the  XI 1  system  might  be  changed  with  latter 
releases,  updates  and  bug  fixes,  the  X  Toolkit  is  a  relatively  stable  application  package  and 
utilizing  it  instead  of  direct  interface  to  the  XI 1  system  calls  would  render  the  software 
more  lasting  and  less  reliant  on  the  system  and  the  update  versions. 

The  X  Toolkit  Intrinsics,  redesigned  for  the  X11R3  windowing  system,  is  intended 
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to  provide  some  basic  mechanism  to  build  sets  of  widgets  for  any  application  environment.  A 
widget  is  the  fundamental  abstraction  and  data  type  of  the  X  Toolkit  and  can  be  visualized 
as  a  blackbox  state  machine  with  associated  input/output  semantics.  Some  widgets  display 
information  like  text  or  graphics  while  others  may  serve  as  a  container  for  other  widgets 
The  Intrinsics  is  built  on  top  of  Xlib  and  serves  as  an  abstract,  object  based  extension  to  the 
X  Window  System.  X  Toolkit  provides  an  interface  which  is  consistent  throughout,  and  a 
small  set  of  intrinsics  easily  used  to  write  applications  and  at  the  same  time  provides  those 
same  set  of  Intrinsics  suitable  for  building  other  widgets.  Because  of  the  way  the  Intrinsics 
is  designed,  constructing  other  widgets  is  almost  trivial. 

In  writing  xnusim,  extra  widgets  such  as  the  “Scroll”  and  “MenuBox”  widgets 
were  constructed  and  used  along  with  the  basic  X  Toolkit  Intrinsics.  Documentation  for 
these  two  widgets  are  available  as  part  of  the  distribution  for  these  new  widgets,  or  may 
be  found,  respectively,  in  the  subdirectories  “Scroll”  and  “MenuBox”  under  the  “xnusim” 
directory. 

2.2  UNIX  4.3BSD  Communication  Protocol 

One  of  the  many  features  in  UNIX  4.3BSD  is  that  of  interprocess  communciation 
(IPC)[LFJ+86,  LMKQ89].  It  provides  capabilities  from  network  level  to  process  level  com¬ 
munications  via  relatively  simple  and  transparent  means.  The  4.3BSD  IPC  allows  different 
processes  to  communicate  via  many  different  ways  and  levels. 

For  the  purpose  of  xnusim,  communication  was  needed  between  that  of  xnusim 
and  the  nusim  simulator.  Nusim  was  designed  primarily  without  considerations  of  whether 
a  higher  level  interface  was  available  and  used,  and  takes  it’s  input  and  output  from  the 
terminal.  Since  one  of  the  goals  of  xnusim  was  to  provide  an  interface  that  was  invisible 
to  the  simulator  as  well,  the  most  appropriate  means  of  communication  was  thought  to  be 
that  of  pseudo  terminals.  The  pseudo  terminal  model  has  two  parts:  a  master  and  a  slave 
terminal  part. 

The  main  process,  for  example,  xnusim ,  may  send  data,  in  our  example,  this 
could  be  a  command  to  nusim,  through  the  master  side  which  will  be  passed  to  the  slave 
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“terminal”  as  stdin.  Any  process  (nusim)  which  exist  at  the  slave  end  will  then  be  able  to 
pick  this  data  up  as  normal  standard  input.  Similarly,  the  process  at  the  slave  end  may 
output  to  either  standard  error  or  standard  output  (stcferr  and  stdout  respectively)  and 
these  will  be  picked  up  at  the  master  end  as  data  from  the  slave  and  may  then  be  processed 
accordingly  (like  output  into  the  main  window  etc). 

Using  this  method  of  communication,  nusim  is  completely  oblivious  to  the  exis¬ 
tence  of  a  process  image  of  xnusim  executing  above  and  controlling  it. 
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Section  3 

Overview  of  Xnusim  and  User 
Reference 


3.1  Design  Considerations 

Xnusim  was  designed  as  an  interface  to  nusim,  but  it  was  also  desired  that  xnusim 
be  sufficiently  flexible  to  be  easily  adapted  to  other  simulators.  Therefore,  an  interface  that 
was  loosely  coupled  to  the  simulator  was  decided  upon.  Loosely  coupled  in  the  sense  that  the 
simulator  has  no  knowledge  of  the  existence  of  xnusim.  and  xnusim  has  little  knowledge  of 
the  workings  of  the  simulator.  And  what  little  xnusim  needs  to  know  about  nusim  in  order 
to  function  wa  localized  into  specific  parts,  so  as  to  minimize  the  modifications  necessary 
to  allow  it  to  fur  '  with  other  simulators. 

Figure  3.1  is  a  simple  construction  of  the  visualization  of  the  design  consideration 
for  xnusim.  In  the  figure,  xnusim  communicates  with  the  user  via  the  X11R3  window 
system,  through  the  use  of  menus,  command  buttons,  and  keyboard  entries.  All  these  are 
processed  by  the  window  system  before  passing  down  to  xnusim.  Xnusim  communicates 
with  the  simulator  (through  IPC)  in  such  a  fashion  that  the  simulator  thinks  it  is  in  direct 
communcation  with  the  user. 

This  method  of  communication  gives  the  most  flexibility  to  xnusim  and  also  frees 
the  programmer  of  the  actual  simulator  (nusim)  from  needing  to  put  the  interface  into 
consideration  when  designing  the  simulator. 
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Figure  3.1:  XNUSIM’s  communication  virtual  view 

The  main  objective  of  xnusim  is  to  provide  a  graphical  interface  which  is  capable  of 
supporting  a  parallel  processor  simulator  and  give  the  user  a  visual  and  easy  to  understand 
mouse-menu  oriented  system.  The  behavior  of  the  simulated  programs  can  be  studied  In- 
observing  the  processors/tasks  displayed  by  xnusim.  Therefore,  the  capability  of  displaying 
information  for  multiple  processor  and  tasks  was  necessary.  But  the  user  must  be  given  an 
option  to  choose  the  number  and  which  of  the  processor/task(s)  to  display  at  will  since  the 
use  of  single  screen  display  limits  the  amount  of  information  possible  (xnusim  can  be  easily 
reconfigured  to  display  on  multiple  screens). 

3.2  Windows 

Xnusim  is  a  window  oriented  display,  and  manages  several  windows,  which  are, 
technically  speaking,  actually  widgets.  And  for  the  purpose  of  this  section  they  will  be  used 
interchangeably  unless  specifically  mentioned  otherwise,  due  to  subtle  technical  differences. 
Upon  startup,  a  large  window  appears  which  contains  several  subwindows,  menu- windows 
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Figure  3.2:  XNUSIM’s  screendump  of  all  stable  windows 
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may  appear  on  request  and  also  windows  for  configuration  and  a  window  each  for  individual 
task/process  that  the  user  chooses  to  display.  The  following  subsections  will  discuss  each 
of  the  type  of  windows.  Figure  3.2  shows  a  diagram  of  most  of  XNUSIM’s  windows,  and  it 
is  suggested  that  this  be  used  for  cross-referencing  the  description  to  follow.  In  this  figure 
xnusim’s  “stable”  windows  are  displayed.  By  stable  windows,  it  is  meant  that  the  windows 
will  not  disappear  the  moment  the  mouse  leaves  that  window.  The  step  sized  has  been  set 
to  2  in  the  figure  as  can  be  noted  by  comparing  the  step  display  in  the  main  debugging 
window  and  the  listing  window. 

3.2.1  Main  Window  I:  Titlebar 

The  titlebar  widget  shows  the  title  currently  assigned  to  nusim  (easily  changed  in 
“defaults.h”  as  “Simulator Name”),  but  also  serve  as  the  sensitive  point  for  starting  up  of 
the  main  menu  which  allows  the  display  of  processors  and  tasks. 

3.2.2  Main  Window  II:  Helpbar 

The  help  widget  simply  display  any  error  message  or  messages  explaining  the  use 
or  name  of  the  window  that  the  mouse  is  in. 

3.2.3  Main  Window  III:  Listing  Window 

This  window  is  where  the  program(s)  being  simulated  is  loaded  into.  There  is 
a  cursor  in  the  window  which  will  always  be  updated  to  point  to  the  current  instruction 
being  executed  after  each  “step”  or  “run”  instruction.  The  user  may  reposition  the  cursor 
anywhere  and  then  set  breakpoints  at  the  position  where  the  cursor  is  (refer  3.2.4).  Nested 
(or  include)  files  are  listed  one  after  the  other  in  the  window,  in  the  order  by  which  the 
simulator  returns  them. 

3.2.4  Main  Window  IV:  Command  Window 

The  command  window  consists  of  several  command  buttons,  and  all  these  com¬ 
mands  may  be  activated  by  pressing  the  left  mouse  button  (unless  otherwise  reconfigured) 
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on  that  command  button.  Below  is  a  short  description  and  explanation  of  the  command 
buttons  as  they  appear  in  xnusim. 

Load  Pressing  this  button  will  create  a  dialog  widget  where  you  may  enter  the  filename  of 
the  byte  compiled  program  which  you  wish  to  simulate. 

Step  Pressing  this  button  makes  xnusim  step  the  simulator  n  times  where  n  may  be  con¬ 
figured  under  the  config  option  (see  below). 

Run  Pressing  this  button  for  the  first  time  sends  the  “run”  command  and  subsequently  it 
will  send  the  “c”  command  (for  continue)  which  will  cause  the  simulator  to  run  itself 
until  the  end,  an  error  or  a  stop  point.  Pressing  reset  (see  below)  will  cause  it  to 
send  the  “run”  command  the  first  time  this  button  is  activated  after  that. 

Breakenv  A  dialog  window  with  two  inputs,  one  for  process  environment,  and  the  other  for  task 
environment,  will  pop  up  and  the  user  may  change  them.  A  return  key  at  either  input 
line  ends  this  function. 

Breakpoint  A  menu  listing  whether  the  user  wishes  to  select  setting  trace/break  points  at  the 
current  cursor  position  or  wishes  to  input  his  own  trace/break  points  and  a  list  of  all 
deletion  options  currently  available  will  be  displayed.  Of  the  list  of  options  offered,  if 
no  breakpoints  were  set,  the  list  of  deletion  options  is  empty;  if  only  one  break/ trace 
point  was  set,  the  list  has  only  that  member;  and  if  more  than  one  were  set,  the  list 
has  the  “delete  all”  option  as  well. 

Breaktime  A  dialog  window  will  be  available  to  set  the  breaktime  (or  delete  it). 

All  three  are  updated  at  the  point  of  pressing  the  button,  so  the  user  may  set/cliange 
these  on  the  main  debugging  window  (refer  Subsection  refdebugwin)  and  the  updates 
will  be  available  here  as  well. 

Config  This  button  activates  the  config  window  which  currently  contains  3  parts: 

-  Step  Where  a  dialog  window  will  pop  up  for  the  selection  of  the  number  of  steps 
which  the  step  button  will  perform. 
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-  Processor  A  configuration  list  of  all  known  registers  for  the  processor  module  will 
be  listed  with  their  current  display  status  (ON  :  display;  OFF  :  not  dislayed)  or, 
if  they’re  variable  (eg  A[0-7]),  the  arrow  in  place  of  the  ON/OFF  display  will 
indicate  that  going  there  will  make  another  window  pop  up  showing  which  of  the 
variable  number  (MAXNUM  set  in  “processor.h”)  register  is  being  displayed. 
The  user  may  press  on  these  button  to  update  the  display  status  of  that  register. 
Update  is  instantaneous  and  the  user  may  leave  this  window  active  while  select¬ 
ing  a  new  processor  to  display.  As  a  policy  decision,  processors  already  being 
displayed  will  not  have  these  update  affect  them.  In  reference  to  figure  reffull- 
windowl  Processor  0  and  Task  0  in  the  figure  were  activated  with  the  default 
registers  selection  and  Processor  1  and  Task  1  were  activated  after  the  set  up 
change  (compare  with  the  “Configure”  windows  on  right  side  of  the  figure  which 
displays  the  register  setup  for  the  new  processor  and  task  and  not  the  default). 

-  Task  Similar  to  the  processor  module. 

Reset  Terminates  nusim  and  restarts  it.  This  allows  the  user  to  be  able  to  start  with  a  clean 
copy  of  nusim  without  the  need  to  quit  xnusim  and  then  re-setup  the  task/processor 
and  other  display  features. 

Quit  Simple  enough:  quits  xnusim. 

3.2.5  Main  Window  V:  Main  Debugging  Window 

This  window  is  where  the  user  will  see  the  bulk  of  the  activity  occur.  The  com¬ 
munication  between  xnusim  and  nusim  will  be  displayed  here,  and  the  user  may  edit  and 
type  in  line  commands  to  nusim  directly  from  here  too. 
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Section  4 

Technical  Details:  Layout  of 
Xnusim 


4.1  Introduction 

Xnusim  is  made  up  of  and  2  widget  library  files  and  14  files,  7  of  which  are  “header” 
(“.h”)  files,  The  library  files  have  their  own  description  and  references,  so  this  section  will 
be  mainly  describing  the  14  files.  The  names  of  procedures  used  in  xnusim  are  shown  in 
Appendix  A.  The  manual  page  for  xnusim  is  found  in  Appendix  B.  The  actual  listings  of 
the  14  files  are  in  Appendix  C.  Of  these  14  files,  2  of  them,  general. c  and  general.h ,  are  files 
which  are  useful  for  any  program  since  commonly  needed  routines  are  placed  there. 

4.2  Descriptions  of  Individual  Files 

•  general.c  and  general.h 

The  two  files  define  the  general  routines  that  may  be  used  for  almost  any  ap¬ 
plication.  Routines  there  maybe  found  in  any  good  C  book.  Included  are  definitions  for 
CALLOC,  MALLOC,  LARGE  and  forever  which  speak  for  themselves,  min  and  max  which 
return  the  larger /smaller  of  two,  error  which  prints  an  error  message  and  may  quit  if  de¬ 
sired,  inchr  and  instr  which  checks  if  a  certain  charactor/substring  is  in  another  string,  and 
hextoi  and  itohex  which  converts  between  hexadecimal  numbers  and  decimal  numbers. 
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•  defaults. h 

In  this  file  is  all  the  default  names  and  sizes  used  by  xnusim,  and  would  probably 
be  changed  by  the  user  when  porting  and  re-adapting  xnusim  for  other  purposes.  This  file 
is  needed  by  all  the  other  files  to  get  their  default  sizes,  fonts  and  name  used. 

•  interface. h 

The  file  which  is  definitely  sensitive  to  the  kind  of  simulator  used.  Defined  in  here 
are  the  types  of  commands  recognized,  what  is  a  PROMPT,  and  the  functions  available  for 
general  use  by  other  files. 

•  mainmenu.h 

Defines  the  window  information  and  callback  functions  for  the  main  menu  (refer 
Section  3.2.1). 

•  manager,  h 

Basic  definitions  for  Xtoolkit  functions. 

•  menucmd.h 


This  is  the  Window  counterpart  to  interface. h.  It  defines  the  commands  which 
appear  in  the  command  window  (refer  Section  3.2.4)  and  the  functions  to  call  (in  handler. c) 
when  that  command  button  is  activated1 . 

For  both  menu  windows  (main  menu  and  command  window),  there  is  a  help  in¬ 
formation  which  is  displayed  whenever  the  mouse  enters  that  button.  This  help  information 
is  displayed  in  the  help  window  ( refer  Section  3.2.2). 


•  processor.h 


lA  button  is  termed  “activated”  when  the  mouse  is  placed  at  that  button  widget  and  the  activation 
button,  normally  the  left  mouse  button,  is  pressed. 
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This  should  be  more  appropriately  called  processor.and.task.h,  but  this  name  was 
chosen  as  it  is  sufficiently  long  without  being  awkward.  This  file  defines  the  maximum 
processors  and  tasks  registers  and  what  they  are,  and  also  defines  the  number  of  variable 
number  register2.  It  also  defines  the  default  registers  of  the  entire  set  which  is  activated. 

•  handler. c 

A  common  module  for  any  Xtoolkit  application  program.  All  the  functions  that  are 
called  when  the  commands  and  menu  buttons  on  xnusim  are  activated  are  described  here. 
This  probably  needs  to  be  modified  whenever  the  commands  are  changed,  but  modifications 
could  be  simply  cut  and  paste  since  most  forms  of  buttons  are  available,  and  any  programmer 
sufficiently  versed  in  C  and  Xll  will  immediately  recognize  the  order  of  changes.  Most  of 
these  makes  calls  to  the  interface. c  module  (most  probably  via  the  sendMsg  procedure) 
which  does  most  of  simulator  dependent  work.  Most  likely  to  change  are  the  “Break”  series 
of  buttons  since  these  were  made  specifically  for  nusim.  But  it  was  deemed  necessary. 
This  module  has  to  be  changed  when  it  becomes  desirable  to  interface  xnusim  with  other 
simulators. 

•  interface. c 

All  of  the  simulator  dependent  functions  are  found  here  (except  for  those  related 
to  processors  and  tasks  some  of  which  may  be  found  in  the  misc.c  file).  A  more  detailed 
discussion  of  some  of  the  functions  in  this  module  is  in  order  and  the  user  is  referred  to 
Section  5  for  that.  This  file  is  the  crux  of  the  interface  between  nusim  and  xnusim.  All 
of  xnusim’s  calls  from  the  user  eventually  ends  up  to  some  routine  in  this  file.  There  is 
a  routine  ( MalnDo )  which  will  recognize  nusim’s  output  and  calls  the  appropriate  routine 
(most  probably  also  in  this  file)  to  update  it’s  values,  like  the  listing  window  (on  load  and 
step/run)  and  the  processor/task  windows  (misc.c  involved).  It  is  possible  to  drop  misc.c 
and  attach  these  functions  here,  but  it  was  decided  to  localize  all  processor/ task  related 
function  to  a  file. 

5  For  the  purpose  of  this  paper,  a  “variable  number  register”  is  a  register  with  suffixes  from  0  to  a  maximum 
number  defined  in  that  file,  like  the  “A”  register  which  may  have  suffixes  from  0  to  7  thus  “AO”-” AT” 
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•  main.c 

Does  the  initial  command  line  interpretation,  performs  the  necessary  “forking”  of 
processes  and  executes  each  correctly.  Trap  for  exit  errors  is  also  found  in  this  file.  The 
user  is  referred  to  the  xnusim’s  manual  page  for  the  list  of  options  available. 

•  manager.c 

This  is  the  main  file  for  interfacing  to  Xtoolkit.  It  does  the  initial  and  main 
graphics  set  up  for  xnusim,  defines  each  window,  and  their  components  and  then  display 
them.  It  also  starts  the  infinite  loop  that  executes  xnusim’s  part  of  the  Xtooikit  interface. 

•  misc.c 


This  file  defines  all  of  the  modules  needed  for  the  processor  and  task  subwindows. 
The  processor  and  task  windows  are  similar  in  nature,  merely  differing  in  names  and  actual 
register  set.  Thus,  modifying  one  would  imply  modifying  the  other  (refer  to  Section  5  for 
details  on  modification).  The  file  contains  the  functions  which  pop  up  each  processor /task 
window,  the  functions  called  when  the  values  need  to  be  updated,  and  the  functions  called 
when  there  is  some  configuration  necessary  for  the  register  sets  for  the  processor /task  win¬ 
dows. 


4.3  Interaction  of  Xnusim’s  Modules 

To  understand  the  interaction  between  these  modules  (files),  the  user  should  get 
familiar  Appendix  A  that  lists  the  functions,  and  which  files  contain  these  functions.  To 
give  a  general  view  of  the  module’s  interaction,  consider  when  the  user  types  in  a  command  . 
or  presses  a  button.  The  eternal  loop  in  manager.c  captures  that  “event”3,  then  the  related 
functions  are  called. 

The  key  events  are  now  described: 

*  events  are  any  form  of  action  related  to  the  widgets,  including  exposure,  keyboard  input,  mouse  input, 
size  change  etc 
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•  If  the  event  is  a  keyboard  input  in  main  window,  these  functions  are  found  in  man¬ 
ager. c  which  is  called  and  then  returned  to  the  eternal  loop  (  forever  line),  unless  the 
“return”  key  is  hit,  whereby  the  keyboard  interpretation  function  in  manager. c  will 
call  interface. c  which  will  transmit  that  command  to  nusim,  and  then  the  eternal  loop 
will  be  returned. 

•  If  the  event  was  that  of  a  button  pushed,  then  the  functions  in  handler. c  will  be 
called  which  eventually  (perhaps  after  some  menu  which  are  found  in  handler,  c)  will 
call  interface,  c  which  will  again  transmit  that  command  to  nusim,  and  then  return  to 
the  eternal  loop  (in  manager.c).  If,  however,  this  button  was  to  perform  some  function 
with  task/processor  windows,  the  file  misc.c  will  be  called  instead  of  the  interface. c. 
Besides  configuration,  however,  misc.c  will  eventually  also  call  interface. c. 

If  there  is  any  output  from  nusim,  then  as  part  of  the  eternal  loop,  the  MainDo 
function  in  interface,  c  is  called.  Here,  the  function  will  detect  the  reply,  does  some  simple 
interpretation  and  then  pass  it  on  to  the  appropriate  functions  in  interface,  c.  When  these 
functions  return,  it  will  then  call  the  processor/task  windows  to  update  the  appropriate 
table.  Note  that  these  will  be  done  iff  an  output  from  nusim  is  expected. 

A  detail  missing  from  the  description  is  that  whenever  read  and  write  is  performed, 
the  functions  MessageRead/ Write  of  main.c  will  be  eventually  called  which  does  the  raw 
biock  transfer  between  xnusim  and  nusim.  These  are  NOT  simulator  dependent  since  they 
merely  transfer  the  raw  bytes  from  the  master  terminal  to  the  slave  terminal  and  vice  versa. 


Section  5 

Interfacing  Xnusim  to  Other 
Simulators 

5.1  Introduction 

As  xnusim  was  designed,  it  was  decided  that  a  desirable  feature  would  be  to 
make  xnusim  sufficiently  general  that  it  would  be  easy  to  modify  it  to  work  with  other 
simulators.  Therefore  xnusim  was  designed  so  that  it  made  as  little  assumption  on  the  way 

the  simulator  performs  as  possible.  Also  due  to  this,  the  simulator  dependent  functions 
have  been  localized  to  only  a  few  modules.  This  section  intends  to  outline  these  modules 
and  methods  of  modifications  that  would  allow  xnusim  to  work  with  other  simulators  that 
adhere  to  the  assumptions  listed  below. 

•  The  simulator  is  assumed  to  have  at  most  multiple  procesesors  and  tasks  of  the  same 
class,  ie,  all  processors  are  homogeneous  in  terms  of  register  sets,  and  similarly  for 
tasks.  In  this  class  of  simulator  is  included  those  simulators  which  have  single  task 
and  single  processor  and  those  with  either  multiple  tasks  or  processors  which  are 
homogeneous. 

•  Upon  receiving  any  command,  the.  simulator  is  assumed  to  output  some  feedback 
messages  which  always  end  with  some  predefined  prompt.  This  feedback  scheme  is 
necessary  only  so  that  xnusim  may  perform  updates  correctly,  while  the  predefined 
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prompt  is  used  by  xnusim  to  recognize  that  nusim  has  stopped  sending  output.  For  this 
reason,  the  simulator  would  need  to  have  some  fixed  number  of  prompts  to  function 
properly. 

•  The  simulator  is  assumed  to  need  to  load  some  source  file  which  is  in  ascii  format. 
Of  this  loaded  format,  it  is  assumed  that  the  simulator  will  deal  with  the  simulator 
at  that  level  as  well  (It  may  or  may  not  deal  with  other  levels  of  coding).  This  is 
required  to  ensure  that  the  listing  window  will  perform  some  useful  update  with  the 
source  code  that  is  loaded.  Nested  files  and/or  include  files  can  be  handled  as  well. 

•  It  is  also  assumed  that  the  simulator  has  command(s)  that  will  enable  xnusim  to 
enquire  about  the  status  of  the  processor/tasks  registers,  current  simulator  position 
in  source  code,  break  points  set. 

Of  course,  these  may  or  may  not  remain  valid  depending  on  the  level  of  changes  made  to 
xnusim,  but  the  simplest  changes  are  necessary  for  those  simulators  adhering  to  the  criteria 
given.  The  following  section  will  discuss  specifically  how  to  modify  xnusim  to  interface  to 
simulators  agreeing  with  those  above. 


5.2  Modifying  The  Interfacing  Module 

There  are  basically  three  things  that  need  to  be  modified  in  xnusim  to  interface  to 
the  new  simulator.  The  first  is  the  way  xnusim  interpretes  an  output  from  the  simulator, 
since  it  is  expected  that  the  simulators  would  definitely  defer  there.  The  modifications  will 
be  localized  in  the  file  interface.c  in  this  case,  and  some  changes  to  the  file  misc.c.  The 
second  is  the  names  of  registers  for  processors/tasks.  This  is  only  in  processor. h.  The  third 
is  the  command  buttons  and  the  way  they  are  handled.  This  is  in  the  module  menucmd.h 
and  hauadler.c. 

5.2.1  Simulator  Communication 

Most  of  the  simulator  interpretation  is  located  in  just  one  file,  interface.c.  The 
only  other  file  is  misc.c  which  has  two  procedures  (one  in  updateTask  and  the  other  in 
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updateProc )  that  are  dependent  to  simulators. 

The  two  procedures  in  misc.c  are  images  of  each  other,  following  the  philosophy 
of  treating  tasks  and  processors  similarly  in  this  simulator,  so  description  of  only  one  is 
necessary.  The  procedure  u pdateTask  first  sends  a  command  to  the  simulator  to  print  out 
the  current  register  condition  for  the  specific  task.  The  simulator’s  output  is  assumed  to  be 
of  the  form1: 

{({<SPC>*<REG>» : ,<SPC>*<VAL><SPC>*>*<rubbiBh>*)*'\n'}* 

If  the  simulator  output  differs,  then  this  procedure  will  have  to  be  modified. 

The  file  interface.c  is  where  the  major  changes  would  be  required.  (Remember  to 
change  interface.h  if  necessary)  Below  is  a  quick  discussion  of  most  of  the  procedures,  the 
rest  would  be  self-evident  after  these. 

needline:  Probably  would  not  need  to  be  changed  unless  there  is  a  change  in  which 
the  interpreter  is  supposed  to  perceive  an  “end  of  output  stream”  from  the  simulator,  which 
currently  is  when  it  reads  a  line  ending  with  the  PROMPT.  It  returns  a  line  that  is  read 
each  time. 

doload:  Needs  to  change  only  the  part  which  sends  the  “load”  command  iff  the 
simulator  does  not  accept  the  command  sequence  of  “load  filename” . 

loadprocess:  Parses  through  the  buf  variable  passed  (raw  bytes  read  in).  It 
assumes  the  buffer  to  be  of  the  form: 

{<rubbish> ' \ * » <FILEHAME » \  ” <rubbish> ' [ ’ <SPC>*<ADRXSPC>* ’ - ’ <SPC>*<ADR>-.SPC>*}* 

where  ADR  is  assumed  to  be  a  hex  address  (see  procedure  gethex)  and  the  content  is 
assumed  to  be  the  filename  and  the  starting  address  and  ending  address  of  the  file  as  it  is 
loaded  in  memory.  (This  probably  would  need  changing  for  another  simulator)  Once  it  gets 
the  filename,  it  loads  the  file  into  the  listing  buffer,  while  updating  the  count  of  number  of 
lines  and  where  each  line  is  in  the  charactor  array  that  makes  up  the  listing  buffer.  The 
loading  part  do  not  need  to  be  changed.  Next  it  tells  the  simulator  to  list  it’s  version  of  the 
code,  and  then  try  matching  it  according  to  the  file  it  loaded.  It  assumes  the  list  to  be  of 
the  format: 

{<ADRXSPC>*  ’ :  ’<SPC>*<CODE><rubbish>  '\n’>* 

'Expressed  as  a  regular  expression,  where  SPO  is  white  space,  REG  is  register  name,  and  VAL  is  value 
of  register 
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And  will  then  match  the  lines  according  to  this  listing,  line  by  line.  It  thus  assumes  the 
simulator  will  NOT  modify  the  code  as  it  is  loaded.  If  the  simulator  does  so,  xnusim  will 
run,  but  will  not  be  able  to  update  the  listing  window  pointer  accurately  and  may  produce 
unpredictable  results. 

updateenv,  updatebreaktm:  These  are  also  reliant  on  simulator  and  are  quite 
similar,  assuming  the  same  command  in  the  simulator  will  provide  information  for  both, 
but  on  different  lines.  Code  is  simple  enough  to  understand. 

updatebreakpt:  This  assumes  the  first  line  would  have  a  if  there  had  been  any 
breakpoints  set,  otherwise  it  returns.  Simulator  should  output  breakpoints  of  the  format: 

{<digit>+* . * [(<rubbish>* : *)U()]<ADR><SPC>*' (' ['b'U’t'] ’) ’<rubbish>’\n'}* 

Where  address  is  the  hexadecimal  address  of  where  the  breakpoint  is  set,  and  the  ‘b’  or 't- 
charactor  indicates  whether  it  is  a  break  or  trace  point.  This  module  probabley  needs  to 
be  changed  for  other  simulators. 

sendMsg:  The  function  which  is  most  important  in  communicating  to  the  sim¬ 
ulator.  Does  multiple  command  communication  to  the  simulator.  For  each  command,  it 
sends  the  command  and  then  returns.  For  some  commands  it  sends  the  command  multiple 
number  of  times. 

MainDo:  This  function  is  the  loop  that  will  read  an  output  from  the  simulator 
if  it  is  expected,  and  assumes  there  will  be  no  more  output  for  the  time  when  it  sees  the 
PROMPT,  and  will  also  branch  to  the  loadprocess  and  updateProc/Task  procedures.  It 
also  respositions  the  listing  window  if  it  detects  movement  in  the  pointer  in  the  simulator. 
Therefore,  it  is  necessary  to  have  the  simulator  output  some  address  information  if  there  is 
to  be  consistent  update  for  the  listing  window  with  the  actual  stepping  of  the  simulator. 

The  changes  in  misc.c  and  interface,  c  will  not  affect  the  execution  of  other  parts  if 
the  information  returned  and  variables  accepted  are  the  same.  It  is  believed  that  regularity 
and  special  keyword  output  from  the  simulator  would  make  interface. c  module  relatively 
simple. 
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5.2.2  Register  names 

The  file  that  needs  to  be  changed  is  processor.h.  For  the  purpose  of  xnusim,  two 
kinds  of  registers  are  distinguished.  The  normal  ones  and  those  with  variable  number,  like 
A[0-7]  for  nusim.  The  constants  which  control  the  number  of  registers  and  the  number  of 
variable  registers  are  self-documented  in  that  file.  The  names  of  each  register  for  processor 
are  in  ptoc  and  those  for  task  are  in  tte,  both  of  which  are  charactor  string  arrays.  Merely 
type  in  the  names  (remember  to  change  MAXLEN  if  there  are  reasons  to  use  registers  name 
with  more  charactors  than  those  defined  there)  in  double  quotes. 

The  variables  procstat  for  processors  and  ttestat  for  tasks  define  the  initial  display 
information  for  xnusim ’s  processor/task  set.  They  define  whether  the  corresponding  register 
defined  in  proc  or  tte  is,  by  default,  being  displayed,  not  being  displayed  or  a  variable  register 
type.  If  it  is  the  variable  type,  the  number  indicates  the  index  (41)  into  the  corresponding 
procvar  or  ttevar  arrays  where  the  same  displayed  or  not  displayed  information,  as  applied 
to  variable  registers,  may  be  found. 

5.2.3  Buttons 

The  last  thing  that  probably  needs  to  be  changed  is  the  handler.c  module  which 
handles  the  button  responses.  For  each  button  that  is  changed,  there  is  probably  need  to 
change  the  menucmd.h  file  which  contains  the  names  of  the  buttons  and  the  functions  they 
call.  The  comments  in  menucmd.h  would  be  sufficient  to  modify  that  file.  In  order  to  modify 
the  file  handler.c,  some  knowledge  of  Xtoolkit  is  necessary.  Since  only  basic  functions  like 
XtSet  Values,  XtPopup ,  XtAddEventHandler  etc  are  used,  basic  knowledge  of  Xtoolkit  and 
XI 1  system  would  be  sufficient  to  understand  and  modify  this  module. 
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Section  6 

Conclusion 

6.1  Summary 

This  paper  outlines  the  entire  project  for  Xnusim,  which  started  as  a  simple  inter¬ 
face  for  a  simulator  under  development  at  that  time  but  developed  into  a  general  debugger 
interface.  The  paper  covered  the  areas  of  what  xnusim  is,  how  xnusim  is  designed,  what  to 
modify  when  changes  are  needed,  and  what  kind  of  support  xnusim  gives  to  and  requires 
from  the  simulator. 

Xnusim  would  definitely  provide  an  environment  that  will  ease  the  user  from  the 
need  to  keep  track  of  several  processors  and  tasks,  and  would  make  it  easier  for  the  user 
to  debug  the  source  code  and  understand  how  the  parallelism  functions  because  it  displays 
most  of  the  essential  information  via  windows  and  allow  the  user  to  perform  several  tasks 
via  simple  button  clicking. 

Xnusim  has  been  shown  to  be  a  powerful  interface  tool  for  simulators.  Writing  a 
simulator  that  is  graphics  in  nature  limits  its  used  to  that  graphics  environment.  Writing 
a  simulator  without  graphics  capability  makes  studying  parallelism  and  debugging  source 
code  a  cumbersome  process.  Thus,  xnusim  serves  as  a  solution  to  this  seeming  conflict.  The 
simulator  may  still  be  used  in  non-graphics  environment  or  any  environment  of  a  different 
nature,  but  when  desired,  xnusim  will  serve  as  the  graphical  link  which  will  solve  the  second 
part  of  the  problem. 
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6.2  Future  Development 

Many  improvements  are  possible  to  xnusim.  Some  of  them  are  outlined  below. 

I  Xnusim  should  become  much  more  user  friendly,  for  example,  the  “loading” 
(which  could  perform  directory  listing)  command. 

II  Xnusim’s  interface  to  the  simulator  could  be  improved,  for  example,  listing  of 
breakpoints  in  the  listing  window. 

HI  There  is  currently  no  summary  information  printed  by  xnusim.  This  is  a  defi¬ 
nitely  desirable  feature  to  be  included.  But  it  has  not  been  included  since  what 
kind  of  information  and  how  these  informations  are  to  be  arranged  and  gathered 
has  not  been  well-defined. 

IV  The  module  handlers  may  be  modified  to  be  sufficiently  general  that  it  will 
become  unnecessary  to  modify  it  for  any  modification  to  the  simulator.  This 
is  possible  if  a  protocol  for  defining  what  kind  of  menus,  how  these  are  to  be 
manipulated  and  what  functions  they  call  is  established.  Then,  the  main  func¬ 
tion  for  interpreting  this  will  be  handler. c’s  heart,  and  possibly  the  procedure 
sendMsg  of  interface. c  would  become  more  sophisticated. 

V  The  next  giant  step  would  be  to  make  interfaces  a  general  file  that  does  some 
form  of  regular  expression  interpretation  and  replies  with  some  regular  expres¬ 
sion,  all  of  which  may  be  defined,  again,  by  some  protocol.  If  this  is  done,  using  a 
configuration  file  of  some  sort  for  the  kind  of  simulator,  xnusim  would  be  able  to 
handle  different  simulators  without  ever  needing  any  recompilation,  and  would 
truely  establish  the  ideal  of  being  a  general  simulator  interface.  (Incidentally, 
this  would  include  the  modifications  mentioned  for  the  handlers  module,  since 
it  would  not  work  otherwise) 

With  these  modifications,  xnusim  would  probably  be  a  very  useful  package  for 
people  interested  in  designing  parallel  systems  at  different  levels,  debugging  programs  that 
are  to  be  used  in  these  systems,  and  studying  the  behaviour  of  different  programs. 
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Procedure  Name 

File  of  origin 

Prototype  of  Procedure 

ClrSel 

manager.c 

XtActionProc  ClrSel(w,  event,  parm,  num) 

DelChar 

manager.c 

XtActionProc  DelChar(w,  event,  parm,  num) 

DelLine 

manager.c 

XtActionProc  DelLine(w,  event,  parm,  num) 

DelWord 

manager.c 

XtActionProc  DelWord(w,  event,  parm,  num) 

Killconfig 

misc.c 

void  Killconiig(w,  client,  call) 

MaiuDo 

interface.c 

void  MainDo() 

MessageRead 

main.c 

int  MessageRead)  buf,  n  ) 

MessageWrite 

main.c 

int  MessageWrite)  buf,  type  ) 

Mmain 

main.c 

main(argc,  argv) 

ModifyProcReg 

misc.c 

void  ModifyProcReg(w,  client,  call) 

ModifyTaskReg 

misc.c 

void  ModifyTaskReg(w,  client,  call) 

ModifyVarReg 

misc.c 

void  Modify VarReg(w,  client,  call) 

SelWordO 

manager.c 

XtActionProc  SelWordO) w,  event,  parm,  num) 

SendCmd 

manager.c 

XtActionProc  SendCmd(w,  event,  parm,  num) 

SetVarReg 

misc.c 

void  SetVarReg) w,  client,  call) 

Siglnt 

manager.c 

XtActionProc  Siglnt(w,  event,  parm,  num) 

bombed 

main.c 

bombed)  sig,  code,  scp) 

breakenv 

handler.c 

void  breakenv) widget,  client,  call) 

breakpoint 

handler.c 

void  breakpoint(widget,  client,  call) 

breaktime 

handler.c 

void  breaktime) widget,  client,  call) 

buttons 

handler.c 

void  buttons) widget,  client,  call) 

config 

handler.c 

void  config) widget,  client,  call) 

configProc 

misc.c 

void  configProc) sendtop) 

coniigTask 

misc.c 

void  configTask) sendtop) 

control 

handler.c 

void  control) widget,  client,  call) 

dialog 

handler.c 

char  *  dialog)  str  ) 

dispbreakpt 

handler.c 

dispbreakpt)widget,  j,  call) 

dispbreaktm 

handler.c 

void  dispbreaktm) widget,  i,  call) 

displayprocess 

handler.c 

void  displayprocess) widget,  i,  call) 

displaytask 

handler.c 

void  displaytask(widget,  i,  call) 

dispsize 

manager.c 

void  dispsize)size) 

dobreak 

interface.c 

int  dobreak)  linenum,  mode  ) 

doload 

interface.c 

static  void  doload)) 

error 

general,  c 

error)  str,  type  ) 

findLine 

interface.c 

int  findLine)  position  ) 

findplace 

manager.c 

int  findplace(str,  posn) 

format 

misc.c 

static  void  format)  label,  name,  val  ) 

gethex 

interface.c 

int  gethex(s) 

getlistposn 

manager.c 

int  getlistposn)) 

getport 

main.c 

void  getport)) 
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Procedure  Name 

File  of  origin 

Prototype  of  Procedure 

handler  Jnit 

handler.c 

void  handlerJnit(pass) 

help 

handler,  c 

void  help(widget,  text,  event) 

hextoi 

general.c 

hextoi(str) 

inchr 

general.c 

inchr(str,  c) 

i nit  .interface 

interface.c 

void  init  Jnterface(size) 

instr 

general.c 

instr(sl,  s2) 

interface-init  .screen 

interface.c 

void  interface_init_screen(scrl,  scr2,  scr3) 

itohex 

general.c 

char  *itohex(val,  size) 

killChild 

main.c 

killChild() 

killWindows 

handler.c 

void  killWindows() 

load 

handler.c 

void  load( widget,  client,  call) 

loadprocess 

interface.c 

void  loadprocess(buf) 

makemenu 

manager.c 

static  void  makemenu (  top  ,  name) 

manageProc 

misc.c 

void  manageProc(n,  top) 

manageTask 

misc.c 

void  manageTask(n,  top) 

manager 

manager.c 

manager(  title,  file,  argv,  argc  ) 

needline 

interface.c 

char  *needline(type) 

printHelp 

main.c 

printHelp() 

procMain 

handler.c 

void  procMain( widget,  client,  call) 

putList 

interface.c 

int  put  List  (  str,  type  ) 

putList2 

interface.c 

int  putList2(  str,  type  ) 

putMain 

interface.c 

int  putMain(  str  ) 

quit 

handler.c 

void  quit(widget,  text,  event) 

reposition 

interface.c 

void  reposition(  line  ) 

reset 

handler.c 

void  reset(widget,  text,  event) 

resetmanager 

manager.c 

void  resetmanager( ) 

run 

handler.c 

void  run(widget,  client,  call) 

sendMsg 

interface.c 

void  sendMsg(  sendcomm,  str,  times  ) 

setdisp 

manager.c 

setdisp(cmd,  dpy) 

startsplit 

main.c 

void  startsplit() 

step 

handler.c 

void  step(widget,  client,  call) 

summMain 

handler.c 

void  summMain( widget,  client,  call) 

taskMain 

handler.c 

void  taskMain  (widget,  client,  call) 

updateProc 

misc.c 

void  updateProc(  n  ) 

updateTask 

misc.c 

void  updateTask(  n  ) 

updatebreakpt 

interface.c 

updatebreakpt(bp,  count) 

updatebreaktm 

interface.c 

updatebreaktm(bt) 

updateenv 

interface.c 

updateenv(task,  proc) 
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NAME 

xnusim  -  X  window  interface  to  a  multiple  processors/tasks  simulator 
SYNOPSIS 

xnusim  [  -toolkitoption  ...  ]  [  -m  host.display  ]  [  -p  host.display  ]  [  -t  host:display  ]  [  -s  simulatorname 
]  [  w-filename  ]  [  -e  simulator _options  ] 

DESCRIPTION 

Xnusim  is  a  graphical  interface  to  a  multiple  processor  and  task  simulator,  currently  implemented  for 
the  simulator  nusim,  but  could  be  modified  to  handle  other  simulators  with  similar  needs.  It  provides 
visual  feedback  and  mouse  input  for  the  user  to  interface  into  the  simulator. 

Xnusim  provides  windows  for  each  processor  (maximum  configurable)  and  task  which  the  user  wish  to 
see,  and  these  are  updated  each  time  the  simulator  returns  from  it’s  tasks. 

The  -mpt  options  are  used  to  describe  the  display  where  each  of  the  main,  processor  and  tasks  windows 
will  be  displayed  (respectively). 

The  simulatorname  option  allows  the  user  to  specify  another  simulator  to  run  under  xnusim.  However, 
reprogramming  is  necessary  to  support  other  kinds  of  simulators.  So,  this  feature,  thus  far,  only  allow 
for  name  changes. 

The  h '-filename  option  allows  the  user  to  specify  a  default  working  file  which  may  be  passed  to  the 
simulator  to  load  once  the  program  is  started  up. 

The  -e  option  should  be  the  last  option.  Xnusim  treats  all  arguments  following  this  option  as  argument 
to  pass  to  the  simulator  Besides  these,  xnusim  accepts  all  of  the  standard  X  Toolkit  command  line 
options  (see  X(l)),  but  is  yet  unable  to  understand  the  simulator’s  options. 


Xnusim  is  made  up  of  the  following  subwindows: 

Title  Bar  Display  the  current  simulator  name.  Also,  when  a  mouse  is  place  in  this  win¬ 

dow,  it  triggers  the  MainMenu(see  Below). 

Message  Window  Display  any  short  Help  message  available  and  or  messages  from  xnusim  to  the 
user. 


Listing  Window 
Command  Window 
Main  Window 


MainMenu 


Display  the  file  that  is  currently  being  executed,  and  shows  the  last  line  that 
had  been  executed  when  stepping  through. 

Provide  a  list  of  the  commands  which  xnusim  understands  and  is  capable  of 
executing.  This  is  also  modifiable. 

This  window  provides  the  actual  simulator  feedback  and  the  user  is  allowed  to 
type  directly  any  command  to  the  simulator  through  this  window  (Note:  update 
MIGHT  not  be  properly  performed  in  that  case). 

Activated  by  the  mouse  entering  the  " Title  Bar ”  region,  it  allows  the  user  to 
choose  to  display/delete  a  processor  or  a  task  from  the  menu. 


The  relative  sizes  of  any  window  in  this  set  can  be  adjusted  to  suit  the  users  needs.  Although  the 
default  size  is  normally  suggested.  To  select  any  command  in  a  button-box,  click  the  left  mouse  but¬ 
ton. 


Scrollbars  can  be  found  in  both  the  Main  and  Listing  windows.  The  left  mouse  button  scrolls  the  text 
forward,  the  right  scrolls  backward  and  the  middl  mouse  button  selects  the  text  at  the  current  mouse 
position  of  the  complete  text  relative  to  the  scroll  bar,  changing  the  thumb  position  of  the  scrollbar, 
r  ragging  the  middle  mouse  button  moves  the  thumb  along  and  changes  the  text  displayed.  The  amount 
of  scrolling  depends  on  the  distance  of  the  pointer  from  the  top  of  the  scroll  bar  (or  bottom).  Top  line 
scrolls  one  line,  and  bottom  one  screenful.  Clicking  the  left  button  twice  quickly  on  either  the  main  or 
listing  windows  will  select  a  word  from  the  window  which  you  may  then  echo  back  by  clicking  middle 
mouse.  Typing  a  command  into  the  debugging  window  will  create  the  same  effect  as  clicking  the 
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mouse  window. 


COMMAND  BUTTONS 
Main  Menu  Commands 

Processor  Another  window  with  a  list  of  processor  will  popup,  and  choosing  the  processor  from 

this  new  window  will  either  delete  it  if  it's  already  being  displayed,  or  create  a  new 
window  for  this  processor  clicked. 

Task  Same  function  as  the  Processor  command  but  for  tasks. 

Summary  To  be  implemented:  will  display  necessary  statistics  for  the  system. 


Commands  In  Command  Window 

Load  Prompts  for  the  filename  and  then  loads  the  ".w"  file.  Can  only  be  activated  once 

because  of  simulator  limitations. 


Step 

Run 

Breakenv 

Breakpoint 

Breaktime 

Config 

Reset 

Quit 


Steps  throught  the  simulator  "n"  steps  a  time  where  n  is  defined  at  the  Config  button 
(see  Below). 

Either  starts  or  performs  continuous  execution  (Note:  the  display  will  not  be  updated). 

Prompts  for  new  values  for  the  processor  and  task  break  environment  (see  Nusim 
reference). 

Allows  user  to  delete,  and  set  breakpoints  (could  set  at  current  cursor  point  in  listing 
window,  program  will  search  for  first  "stoppable"  code  memory  for  inserting  the  stop. 

Allows  setting  and  resetting  of  the  breaktime. 

Allows  reconfiguration  of  a  number  of  things.  Pressing  it  pops  up  a  new  window 
where  user  can  select  the  particular  type  to  configure. 

Resets  the  system  so  that  you  may  re-run  the  simulator  without  need  to  exit  the  sys¬ 
tem.  Since  the  simulator  is  actually  re-runned,  the  whole  system  is  completely 
refreshed.  The  only  window  which  is  not  affected  is  the  main  (debugging  display) 
window  which  merely  reprints  a  start  up  line  after  the  last  line.  This  is  so  that  you 
may  click  from  the  lines  above  to  copy  down. 

Exits  xnusim. 


LIMITATIONS 

Xnusim  is  still  underdeveloped.  Much  needs  to  be  done. 

BUGS 

Probably  quite  a  lot.  Still  shaky  because  of  inherent  problems  with  socket  communications  and  Xtl  1 . 
COPYRIGHT 

Copyright  1989  Regents  of  the  University  of  California. 

AUTHOR 

Pang  Swee-Chee,  University  of  California. 
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